Documentation Index
Fetch the complete documentation index at: https://docs.enfuce.com/llms.txt
Use this file to discover all available pages before exploring further.
The practices described on this page are mandatory for customers using Enfuce BIN Sponsorship and strongly recommended for all processing customers.
Overview
Enfuce’s fraud monitoring gives your programme a strong baseline of protection. But the most effective programmes layer Enfuce’s detection capabilities with proactive cardholder communication and smart use of the controls already built into the platform. This page covers three areas where small changes to how you operate can significantly reduce your fraud exposure.SCA fraud trends
Strong Customer Authentication (SCA) was introduced to make card-not-present transactions more secure. It has largely succeeded — but fraud has adapted. The main threats today don’t break SCA; they manipulate the cardholder into completing it on behalf of a fraudster. Common SCA fraud patterns to watch:- Device takeover via social engineering — a fraudster calls posing as the cardholder’s bank or a trusted brand, convinces the cardholder to approve a push notification or enter an OTP, and uses that authentication to authorise a fraudulent transaction.
- Tokenisation abuse — a fraudster obtains card details and provisions a new digital wallet token on a device the genuine cardholder doesn’t control. The token passes SCA at enrolment. If the cardholder isn’t immediately aware their card has been tokenised to an unknown device, fraudulent transactions can follow.
- Scam-driven authorisations — the cardholder genuinely authorises the payment but has been deceived about its purpose (often called Authorised Push Payment or APP fraud in account-to-account contexts, but increasingly seen in card programmes too). In all of these cases, the transaction looks authenticated and legitimate to the fraud engine. No monitoring system can reliably distinguish a coerced or deceived authorisation from a genuine one — which means the most important line of defence is the cardholder themselves.
- Question unexpected contact. Legitimate banks, card issuers, and payment providers do not call cardholders and ask them to approve a notification, read out an OTP, or transfer funds to a “safe account.” If a caller, SMS, or email creates urgency around a payment action, it is almost certainly fraud.
- Verify before acting. If a cardholder receives an authentication request they didn’t initiate — a push notification, an OTP, a 3DS challenge — they should stop, not approve it, and contact their issuer through the official number on the back of their card.
- Treat unfamiliar transactions as a signal. A small test transaction at an unusual merchant, a new wallet provisioning notification, or a login alert they didn’t trigger are all early warning signs. Cardholders who know to act on these signals immediately reduce the fraud window from hours to minutes. This is not a one-time onboarding message — it requires repeated, contextual reinforcement. The right moment to remind a cardholder that their issuer will never ask them to approve an unexpected push is immediately after they receive a legitimate push notification. The right moment to explain tokenisation fraud is when they first add their card to a wallet. Build the education into the product touchpoints, not a single terms-and-conditions paragraph they will not read.
Using Enfuce webhooks to alert cardholders at sensitive moments
Enfuce sends webhook events when key card lifecycle and fraud-related actions occur. Two event types are particularly valuable here: Tokenisation events When a new digital wallet token is provisioned for a card, Enfuce fires a webhook. If you surface this to the cardholder in real time — via push notification or SMS — they will immediately know if someone else has added their card to a device they don’t recognise. This gives you a near-zero-latency fraud signal before any fraudulent spend occurs. Fraud case notifications When Enfuce’s monitoring engine flags a suspicious transaction and creates a fraud case, a webhook is fired. Passing this event directly to the cardholder — as a push notification or in-app alert — means they are informed the moment a concern is raised, rather than waiting for your operations team to reach out manually. This speeds up verification and reduces the window in which additional fraudulent transactions can occur. Integrating these two webhook types into your cardholder notification flow is one of the most impactful things you can do to reduce SCA fraud exposure.Usage limiters
Every card in your programme has configurable spending controls available via the Enfuce API — per-cardholder limits on transaction amounts, daily or monthly spend, number of transactions per period, merchant categories, and geographies. These controls are commonly used for expense management and employee benefit programmes, but they are equally powerful as a fraud mitigation layer for consumer products. The principle is simple: a cardholder who has set their own limits provides an attacker with a much smaller window to exploit. Recommended approaches: Expose limits in your cardholder app or portal. Cardholders who can self-serve their own controls are more engaged, and self-imposed limits act as a natural backstop against fraud. A cardholder who only ever shops domestically can block international transactions themselves. A cardholder who never uses contactless over €50 can set that ceiling. Prompt cardholders to configure limits at card activation. The moment of onboarding is the highest-engagement point in the card lifecycle. A short “set your spending preferences” step at activation significantly increases the proportion of cardholders who have active limits in place. Use limits as a cardholder-controlled scam defence. Many authorised fraud and scam scenarios involve a single large transaction or a rapid sequence of smaller ones. Cardholders who understand they can set a per-transaction cap, a daily limit, or a “pause international spending” toggle have concrete tools to reduce their own risk — and they tend to use them when you tell them those tools exist. Consider category-level defaults. For product types where certain merchant categories are inherently out of scope (for example, a fuel card where gambling MCCs are irrelevant), blocking those categories by default and documenting the process to unblock them reduces attack surface without requiring cardholder action.Spending limits and controls are configurable via the card management endpoints of the Enfuce API. Changes take effect immediately and can be made by the cardholder through your application or by your operations team through the portal. See the API reference for the full list of configurable parameters.
SMS and push notifications
Fraud and scam losses are not just a financial problem — they are a trust and retention problem. Cardholders who are surprised by a fraudulent transaction, or who feel they weren’t warned, are far more likely to churn. Over-communication is almost never the complaint. The principle here is straightforward: every sensitive card event should produce a notification to the cardholder as close to real time as possible. The notifications don’t need to be alarming; they just need to be consistent and informative. Events that should always trigger a notification:| Event | Why it matters |
|---|---|
| Card activated | Confirms legitimacy; fraudster-provisioned cards can be caught here |
| New digital wallet token provisioned | Immediately surfaces tokenisation fraud (see SCA section above) |
| Transaction approved | Standard spend notification; unusual merchant or country stands out to cardholder |
| Transaction declined | Cardholder knows to contact support; decline reason context helps |
| Card blocked or status changed | Informs cardholder before they attempt to use the card |
| Fraud case opened | Triggers cardholder to verify transactions before being contacted |
| Card replacement ordered | Confirms the cardholder initiated it; flags if they didn’t |
| Spending limit changed | Critical for detecting account takeover where limits are raised before fraud |
Your card ending 4521 was just added to a new digital wallet. If this wasn’t you, tap here to block your card and contact us.
A transaction of €240 at [Merchant Name] is under review by our fraud team. If you recognise this purchase, no action is needed. If you don’t, tap here.Short, specific, and actionable. Avoid generic language that cardholders learn to ignore.